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1 Scope 

Mission-critical events are defined in the Jet Propulsion Laboratory’s Flight Project 
Practices [7] as those sequences of events which must succeed in order to attain mission 
goals. These are dependent on the particular operational concept and design reference 
mission, and are especially important when committing to irreversible events. Critical 
events include main engine cutoff (MECO) after launch; engine cutoff or parachute 
deployment on entry, descent, and landing (EDL); orbital insertion; separation of payload 
from vehicle or separation of booster segments; maintenance of pointing accuracy for 
power and communication; and deployment of solar arrays and communication antennas. 
In each of these events, critical functionality is provided by the major subsystems (e.g., 
propulsion, power, communication, attitude control, and life support) and a failure in one 
or more subsystems may lead to mishap. 

The central objectives of the Critical Event Insight Task are to: 

• Report on the current practices in handling mission-critical events in design and 
operations at major NASA spaceflight centers 

• Report on recommended best practices for mission design and operations for 
critical events 

This report addresses the first objective. The scope of the report includes NASA 
Johnson Space Center (JSC), NASA Goddard Space Flight Center (GSFC), and NASA 
Jet Propulsion Laboratory (JPL), with staff at each center consulted on their current 
practices, processes, and procedures. These centers were chosen based in part on their 
strong mission focus, and on available contacts. 

A major operations phase of an active mission has been selected at each center: 
rendezvous and docking operations for Space Shuttle with Space Station at JSC; on-orbit 
operations for remote sensing satellites at GSFC; and surface operations for Mars 
exploration rovers at JPL. For each mission, critical events will be identified and 
analyzed in this report. In addition, mission design and operations practices and 
procedures that support critical events at each center will be explored. 

A follow-on report will address the second task objective. The approach will be to 
make recommendations on principles and best practices to identify the intersection 
between critical events, system functions, and observable state variables that will support 
anomaly resolution and other decision making relative to system perfonnance. The 
follow-on report will also be a preliminary report; it is to be expected that a more formal, 
binding report would require extensive further work with NASA centers to develop a set 
of agreed-upon best practices, and that is beyond the intended purpose of this infonnal 
report. 

1.1 Purpose 

The Critical Event Insight Task was generated in response to the Diaz Team Report 
Actions (see the Diaz Report [1] and the Columbia Accident Investigation Board Report 
[2]). Related Diaz Actions are: 

• Review/develop current policy or guidance that assures critical event data is 
collected, observed, and analyzed 
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• Develop a standard for comprehensive program risk management and observable 
data collection for all phases of program development, test, operation, and 
enhancement to be used for program management, improvement, and 
anomaly/disaster reconstruction 

• Identify methods used by other test organizations to perform remote system 
testing and anomaly resolution 

1.2 Terminology 

For the purposes of this report, critical events are defined as those events that must be 
successful, in order to meet mission goals. This meets the JPL definition of the tenn. 
GSFC and JSC generally understand the concept of a critical event to mean an anomaly 
or hazardous condition. The distinction to be made is that anomalies are failures that may 
or may not involve critical events. Failed critical events result in mishaps. In the worst 
case, an anomaly compromises achievement of mission objectives and hence the critical 
event, resulting in a mishap. Mishaps are catastrophic failures often categorized as loss of 
mission (LOM), loss of vehicle (LOV), or loss of crew (LOC). 

A distinction may also be made between “hard” critical events and “soft” critical 
events. Hard critical events have irreversible consequences (mishaps) should the critical 
event fail. Soft critical events have reversible consequences and hence may be 
recoverable. Should a soft critical event fail, the result is a system anomaly and disabled 
or impaired functionality required to meet mission goals, with the possibility of a 
workaround requiring intervention. 

Other related concepts are flight rules and safety rules, which are procedures 
developed to ensure successful completion of critical events. 
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2 The Role of Critical Events in NASA Mishaps 

A Mishap Cause Classification (MCC) study [11] identified recurring problem areas and 
trends in NASA mishaps, through the systematic analysis and classification of causes 
across a representative set of mishaps. The approach used was to develop and apply a 
classification method and taxonomy of systemic causes of mishaps, and of subsystems 
and cross-system elements involved in mishaps. Management Oversight and Risk Tree 
(MORT) was used as the basis for the mishap cause taxonomy. 

Analysis of 2 1 mishaps yielded the most frequently cited categories of mishap cause 
(insufficiencies in design, test, and management processes; limitations of human 
perfonnance and procedure implementation), as well as the subsystems most often 
involved (structures and mechanisms, propulsion, control, guidance, and navigation). The 
cross-system elements most frequently cited were subsystem interactions, software, 
humans-in-the-loop processes, materials, and the environment. Trends were identified 
suggesting that unintentional subsystem interactions have become a significant cause of 
mishaps since 1997, and that design problems have remained consistently high since 
1995. 

This report looks beyond mishaps, encompassing critical events during nominal and 
anomalous operations that have the potential to lead to mishaps. The focus of the analysis 
is shifted to the moments before committing to the fatal event. At the GO/NO-GO 
checkpoint for the critical event, this is the last chance to assess the pre-commit criteria 
and infonn the decision whether it is safe to continue. 

The approach used is to identify the critical event that failed for each mishap; list the 
pre-commit criteria in terms of measurements or telemetry readings that fonned the basis 
for the decision; list the desired state of those parameters after the critical event, had it 
been successful; and finally show the actual outcome of the mishap in tenns of 
anomalous parameters, as well as the root cause fault and implicated subsystem(s) or 
functionality that failed. Table 1 below catalogues several NASA mishaps in terms of 
their critical events. Mishap reports comprehensively document the Mars Polar Lander 
[3], Mars Climate Orbiter [4], Mars Observer [5], CONTOUR [6], NEAR [18] and 
Challenger [19] mishaps. 

The question is: what were the missing criteria or anomaly detection capabilities 
that would have prevented a “GO ” decision, if any, with its irreversible consequences. In 
many cases, the system is under-sensed and could not provide these distinguishing 
measurements. For example, the hydrogen leak in the SSME nozzle tubes could have 
been detected by an on-board optical plume anomaly detection (OP AD) system. In some 
cases, the decision could have been supported by piecing together existing information 
from a variety of sources, such as the Mars Polar Lander premature engine cutoff due to a 
faulty sensor that indicated touch-down. A check of altimeter or system state, deploying 
legs, could have prevented engine shutoff at 40 meters above the Martian surface. 

All of these mishaps relate to propulsion. Orbital insertion/departure proved the most 
hazardous mission phase, followed by launch and EDL. System engineering appears as a 
cause in more than half of these cases, in agreement with the MCC study’s most 
frequently cited cause as “insufficiencies in design, test, and management processes.” 
However this sampling is statistically too small to be representative of NASA missions in 
general. 
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Table 1: Critical Events and Outcomes in Mishaps 
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3 Critical Events at NASA Johnson Space Center 

3.1 JSC Mission Design Practices 

The focus of JSC is on operation of human spaceflight for Space Shuttle and International 
Space Station (ISS). JSC therefore does not require the equivalent of the GSFC Gold 
Book or the JPL Flight Project Practices handbook, which specify practices and 
procedures for the design, development, and verification of flight systems. 

3.2 JSC Operations Procedures 

The JSC Mission Operations Directorate (MOD) and the Flight Director Office govern 
Shuttle and ISS operations through a series of Flight Rules documents. These are the 
“Generic All Flights Books”: 

• Volume A - “Space Shuttle Operational Flight Rules” 

• Volume B - “ISS Generic Operational Flight Rules” 

• Volume C - “Joint Shuttle/ISS Generic Operational Flight Rules” 

• Volume D - “Soyuz/Progress/ISS Joint Flight Rules” 

In order to focus the discussion, this section concentrates on the preparation for and 
handling of critical events for ISS as documented in volumes B and C, “ISS Generic 
Operational Flight Rules” and “Joint Shuttle/ISS Generic Operational Flight Rules.” 

The process for development of JSC operations procedures is as follows. The JSC 
program office utilizes a Hazard Analysis process to identify and analyze critical events. 
The program office and vendors detennine potential hazards and document these in 
Hazard Reports. For example, a hazard report may specify the risks of a space shuttle 
Reaction Control System thruster plume impacting an ISS solar array during docking, 
thereby damaging or breaking the solar array. These hazard reports are flowed down to 
the MOD to identify and implement appropriate Operational Controls such as specific 
procedural steps (turn the solar arrays away from the plume), Flight Rules (verify that the 
solar arrays are turned away), and/or crew training (check solar array orientation before 
approaching within 400 ft of ISS). 

Examples of critical events for ISS, identified in this hazard analysis process, 
include: 

• Attitude handover - transition from use of Russian attitude control capabilities to 
US attitude control capabilities (and vice versa) 

• Shuttle docking - reconfiguration of systems to withstand shuttle thruster plumes 
and impact forces of shuttle docking 

• Command and Control Modulator/Demodulator (MDM) transition - handover of 
primary control of the vehicle from one computer to another 

• Software uplink - update to onboard software by transmitting software patch to 
onboard mass storage, subsequent transfer of the software image to an MDM that 
is not in primary control of vehicle systems, followed by handover of primary 
control to that MDM 
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3.3 JSC Critical Events for Rendezvous and Docking of Space Shuttle with ISS 

As the full suite of operations procedures and flight rules for ISS is enonnous, the 
following analysis focuses only on critical events involved in the rendezvous and docking 
operations for Space Shuttle with ISS. Flight rules from the JSC docking operations 
policy are listed in Appendix A - JSC Rendezvous Operations Procedures. The following 
flight rules impose constraints associated with rendezvous and docking: 

• C2-56 - Shuttle Go-No Go for Docked Operations 

• C2-101 - ISS Go-No Go Matrix for Rendezvous 

• C2-104 - ISS System Management for Approach and Dock 

• C2-105 - Shuttle Sensor Requirements for ISS Proximity Ops 

These rules, in turn, reference other flight rules which are not included here, that 
define required configurations prior to execution of docking operations. 

Flight rules in C2-56 govern continued Shuttle docked operations. The major 
constraint that must hold is that, while docked, Shuttle must retain sufficient propellant 
for emergency undocking and de-orbit to the nearest landing site. C2-105 flight rules 
cover sensor needs to ensure safe Shuttle approach to ISS, such as redundant ranging 
devices including hand-held LIDAR (Light Detection and Ranging) to measure distance, 
speed, and rotation of Shuttle relative to ISS. 

Criteria for successful completion of docking are at least partially addressed in flight 
rule C2-104. C2-104 (A) has procedures for ISS appendage configuration, specifically to 
ensure that the solar arrays are out of the line of approach. Thruster or external venting 
plume impingement can create adverse and unpredictable structural torques and 
unacceptable localized heating, as well as contaminate critical surfaces and degrade 
material properties. 

C2-104 (B) states that micro-switches on ISS and Shuttle must detect that the 
docking mechanism has contacted. That, in turn, causes the vehicles to go to free drift (no 
attitude control). Free drift condition is required to ensure that neither vehicle applies 
forces or torques to the docking mechanism before it is ready. There are other actions and 
criteria after this to ensure that the two vehicles are completely mated and a good 
pressure seal exists between them, but these are excluded from this analysis. 

Critical events for ISS rendezvous and docking are analyzed in Table 2. The flight 
rules are correlated to GO/NO-GO checkpoints, and broken down according to different 
possible operational scenarios. Pre-commit criteria for nominal (GO) conditions and 
anomalous (NO-GO) conditions are identified. Expected nominal post-commit conditions 
and anomalous post-conditions with recovery procedures, where supported, are 
identified. Telemetry or measurements which are the basis for the pre-commit criteria are 
identified. The overall mission phase that the critical event applies to, and any other 
related flight rules for this critical event, are specified. Finally, systems and subsystems 
involved in the interaction are identified. As expected, all of these events show 
interactions between subsystems, as well as interactions between systems. 
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4 Critical Events at NASA Goddard Space Flight Center 

4.1 GSFC Mission Design Practices 

Goddard is involved in the design and operation of unmanned Earth science missions. 
“Rules for the Design, Development, Verification, and Operation of Flight Systems,” aka 
the Gold Book, is GSFC’s highest-level technical design standard for flight systems [9]. 
The GSFC systems engineering process explicitly covers telemetry for mission-critical 
events. The aim is to ensure that required telemetry is monitored during all mission- 
critical events to support anomaly investigations in the event of a mishap, so that future 
problems of a similar nature can be avoided. 

The GSFC practices and procedures for incorporating critical events into mission 
design are as follows. At Mission Concept Review (MCR), mission-critical events are 
identified in the Concept of Operations. At Mission Definition Review (MDR), 
requirements for coverage of critical events are identified in ground system design. At 
Preliminary Design Review (PDR), operations for mission-critical events are addressed 
in the Mission Operations Concept and requirements for critical-event coverage are 
specified in the ground system design. Telemetry and command coverage of critical 
events is flowed down to the Operation Plan at Critical Design Review (CDR), and to the 
Operations Procedures at Operational Readiness Review (ORR). Finally, during mission 
operations checkout, the telemetry capability to support monitoring of critical events is 
verified. 

In addition to design for critical-event monitoring, the Gold Book contains many 
lessons learned or rules of thumb for mission design. For instance, the Genesis mishap 
could have been prevented by Gold Book Rule 1.33: Polarity Checks of Critical 
Components, which states that “All hardware shall be verified by test or inspection of the 
proper polarity, orientation, and position of all components (sensors, switches, and 
mechanisms) for which these parameters affect performance.” The rationale is that each 
spacecraft and instrument contains many components that can be reversed easily during 
installation. Unless close inspections are performed, and proper installations are verified 
by test, on-orbit failures can occur when these components are activated. This is precisely 
what happened on Genesis: The gravity switches to trigger deployment of the parachute 
were installed backwards and the spacecraft fell to its destruction. 

The Mars Climate Orb iter (MCO) mishap is addressed by Gold Book Rule 1.12: 
Units of Measurement which states that “All design elements shall be specified and 
designed to ensure the consistent and compatible use of physical units of measure.” The 
rationale is that critical functions can be misrepresented by errors in unit conversions. 
MCO missed orbital insertion around Mars, as an erroneous trajectory was computed 
using data in English units instead of metric units. 

These particular mishaps could likely not have been prevented solely by critical 
event monitoring; once launched with gravity switches installed backwards, the Genesis 
mission was doomed (unless parachute deployment could be remotely commanded). 

4.2 GSFC Operations Procedures 

Goddard utilizes a combination of on-board fault protection and ground control to ensure 
spacecraft safety during operations. The spacecraft fault protection system is automated, 
as described in Appendix B - GSFC Automated Fault Protection. The spacecraft flight 
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software monitors key limits using a combination of Telemetry Statistical Monitors 
(TSMs) and Fault Detection and Correction (FDC) redlines, typically operating on single 
telemetry points. The TSM rules monitor the spacecraft at the system level, and are 
typically executed by Command and Data Handing (C&DH). The FDC rules are 
monitored for a particular subsystem only, and are executed within that subsystem. If a 
rule is triggered, indicating a violation of some safety or nonnal operations constraint, an 
automated recovery action may be initiated by a series of pre-programmed commands, 
the Relative Timed Sequence (RTS). 

Ground control of spacecraft operations is semi-automated, using predefined 
procedures written in the Systems Test and Operations Language (STOL), and executed 
by the Advanced Spacecraft Integration and System Test (ASIST) ground command and 
control software at the Mission Operation Center (MOC). A suite of STOL procedures is 
developed to support operations for a mission. These procedures are sets of commands 
that can be issued by the MOC during a ground contact that the spacecraft will respond 
to. STOL procedures can include checks for required preconditions and expected 
responses, and as such implement GO/NO-GO checks on critical events in the system. 

In general, the Goddard approach is to design out known anomalies as much as 
possible, and to respond to escapes through a combination of on-board fault protection, 
spacecraft sating, and ground-directed recovery. There are no critical events defined that 
require operator intervention within a specified time to ensure mission success. Recent 
efforts have been to increase automation and reduce the need for operator oversight, to 
reduce mission operations costs. 

A few examples of critical events for remote sensing and earth science systems are: 

• Science data collection and recording activities, instrument and sensor calibration 

• Ground contacts to allow: 

o Uplink of commands to spacecraft, including absolute time command 
(ATC) loads and contingency operations 
o Science data downlink telemetry 

o Real-time and playback of state of health and satellite monitoring 
telemetry 

• Station-keeping and orbital maneuvers 

• Pointing accuracy for solar arrays (towards the Sun) and communication antennas 
(towards Earth). 

• On-orbit separation and checkout, and deployment of the solar array 

For satellite constellations, orbit fonnation operations are also critical events. For 
example, Earth Observing One (EO-1) is in polar orbit behind Landsat-7 (L7) by one 
minute. Weekly orbital maneuvers must be perfonned in order to maintain the L7 co-fly 
profile. This facilitates co-imaging activities and prevents collision between the satellites. 

4.3 GSFC Critical Events for Earth Sensing Satellites 

Critical events for earth observing missions are analyzed in Table 3. These critical events 
are based on contingencies for the Earth Observing One (EO-1) satellite. 
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5 Critical Events at NASA Jet Propulsion Laboratory 

5.1 JPL Mission Design Practices 

JPL-specific standards for flight systems that address critical events are the “JPL Flight 
Project Practices” [7] and the “JPL Design, Verification/Validation and Operations 
Principles for Flight Systems” [8]. Other related documents are JPL Standard for Systems 
Safety [12], JPL Anomaly Resolution [13], and JPL Reliability Assurance [14]. 

JPL defines mission-critical events as those that if not executed properly, could result 
in failure to achieve mission success (e.g., orbit insertion, EDL). Fault tolerance design 
principles include sequence continuation in response to non-survival-threatening 
anomalies; safing in response to survival-threatening anomalies, requiring ground 
intervention for recovery; on-board backup sequence execution in the event that 
command upload capability is lost; and ample diagnostic engineering telemetry, 
including telemetry data downlinked for critical events. 

Prior to launch, projects develop the flight sequences for launch and early flight 
operations, and develop a baseline version of mission-critical sequences (orbit insertion, 
entry/descent/landing, launch and launch vehicle separation, deployments, etc.) and 
mission-enabling sequences (science operations, aero braking, safing, etc.). JPL defines a 
series of documents that address sequences for mission-critical events, including 
Sequence Activity Plans, Spacecraft Anomaly Recovery Plans, Contingency Plans, and 
Flight Rules and Constraints. These are defined specifically for each mission. 

Flight sequence design for critical sequences ensures telemetry visibility for real- 
time monitoring and verification of mission-critical events. This requires sufficient 
telemetry data to rapidly assess spacecraft state and health status under normal and 
faulted operations, so that ground operators can detennine rapidly and unambiguously the 
state of the spacecraft early in the ground tracking pass, including whether the spacecraft 
executed a fault protection response. Adequate telemetry data and sampling frequency, 
including any special diagnostics, are required to enable the flight team to perform 
anomaly determination, investigation, and reconstruction. 

Mission design provides for redundant handling of mission-critical sequence data 
with simultaneous real-time transmission and on-board storage. On-board storage 
protects critical data against loss in the event of selected anomalies, (e.g., transient power 
or communications outage). The design also includes the design of fallback or 
contingency options that specify how the mission will adapt to failures or performance 
shortfalls in mission-critical systems. Missions with single-string design for critical 
events may need to increase functional redundancy or control algorithm robustness. 
Single-string design is acceptable if the demonstrable risk is acceptable. 

Mission assurance practices include Hazard Analyses, which identify and assess 
hazards associated with the design and operation of flight hardware and mission-critical 
software. Initial analyses are perfonned as early as practical in the formulation phase and 
are updated as needed through launch. For hardware, single points of failure that are part 
of success-critical functions are identified by Failure Modes, Effects, and Criticality 
Analysis (FMECA) for electrical/electronic hardware, or by a Fault Tree Analysis for 
devices, mechanisms, and electro-mechanical hardware. Risk assessments evaluate the 
measures implemented to minimize risk, including alternate operating modes, operational 
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workarounds, and telemetry sources of failure information. Single points of failure are 
eliminated from the design where possible, or a waiver is requested. 

Software quality assurance includes verification of the software traceability matrix to 
ensure that requirements are correctly implemented and that critical mission software has 
been appropriately tested. For safety/mission-critical flight software with a significant 
risk, the NASA Independent Verification and Validation (IV &V) Facility is used. 

The mission team performs system-level functional V&V of the launch sequence and 
early flight operations on the flight vehicle, using the launch version of flight software. 
Commands and sequences for all critical events are developed, tested, and verified prior 
to launch. This includes validation of baseline versions of mission-critical sequences and 
mission-enabling sequences. Verification is by functional simulation, and includes checks 
of flight rules and resource utilization constraints (e.g., power, data rate, thennal 
conditions). 

5.2 JPL Operations Procedures 

Mission operations practices are documented in the “JPL Flight Project Practices” [7]. 
Operations teams give special attention to checkout of flight system functionality, and the 
development of sequences for mission-critical events, especially for irreversible events. 
Critical Event Readiness Reviews (CERRs) are conducted sufficiently in advance of 
critical events to allow time for correction of deficiencies. Prior to irreversible events, the 
operations team assures safe, reliable operation in the design of sequences, for instance 
by reviewing relevant development history including red-flag PFRs (problem/failure 
reports). Prior to mission-critical events, the operations team identifies what could go 
wrong (e.g., using an event fault tree) and develops contingency plans to ensure that each 
critical event occurs. When a time-critical response is required, contingency surface 
operations procedures and sequences are generated and validated to the level needed to 
facilitate a rapid response. 

The readiness of the operations team for upcoming critical events is demonstrated for 
both nominal and off-nominal conditions by Operations Readiness Tests (ORTs). Prior to 
uplink of the critical event sequence, the sequence is validated by testing nominal and 
off-nominal execution on the Flight System Testbed, by internal review of the sequence 
and by external walkthrough of the sequence and review of the testbed test results. The 
operations team manager approves the critical event sequences, as well as any waivers to 
flight rules that may be necessary. 

The command load for the next day’s activities is generated during each nighttime 
period for the spacecraft, validated, and then uploaded to the spacecraft. Prior to 
command load execution, successful upload of the sequence is verified, for instance by 
checking the on-board memory for corruption that could result from single-event upsets, 
using checksum telemetry. 

All sequences should execute pre-stored, pre-validated Relative Time Sequences 
(RTSs) for standard kinds of regularly used functions where available, instead of 
including new commands for those functions in the new sequence. Relative or event- 
driven sequences are pre-stored for foreseeable repeating functions, to be available for 
reuse in new sequences without requiring re-validation. At a minimum, non-standard 
portions of sequences that have not previously been validated shall be simulated on the 
testbed prior to being uplinked to the spacecraft. A portion of the sequence is non- 
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standard if it contains a single command not normally belonging to the standard 
sequence, or if it has not been tested previously on the testbed. 


5.3 JPL Critical Events for the Mars Exploration Rovers 

Critical events for rover surface operations for the JPL Mars Exploration Rover (MER) 
program are analyzed in Table 4. MER critical events are based on constraints listed in 
Appendix C - JPL Mars Exploration Rover Flight Rules, as well as an extensive 
spreadsheet of MER flight rules that is too lengthy for inclusion in this report. Additional 
critical event information has been taken from the JPL CLARAty project. CLARAty 
(Coupled Layered Architecture for Robotic Autonomy) is a robotic architecture that is 
being used to mature and validate technology for infusion into future JPL rover missions. 

Some acronyms used in the table are: 


Absolute Time Command (ATC) 

Acquisition of Signal (AOS) 

Alpha-Particle X-ray Spectrometer (APXS) 
Battery State of Charge (BSOC) 

Charged Coupled Device (CCD) 

Command and Data Handling (C&DH) 

Deep Space Network (DSN) 

Flight Software (FSW) 

High Gain Antenna (HGA) 

Inertial Measurement Unit (IMU) 

Instrument Ann (IA) 

Instrument Deployment Device (IDD) 

Loss of Signal (LOS) 

Microscopic Imager (MI) 

Mini-Thermal Emission Spectrometer (Mini-TES) 
Mission Clock (MC) 

Mission Elapsed Time (MET) 

Mossbauer spectrometer (MB) 

Quaternion (rover position estimate) 

Rock Abrasion Tool (RAT) 

Solar Array (SA) 

State of Health (SOH) 

Universal Coordinated Time (UTC) 

Visual Odometry (VO) 
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Table 4: JPL Rover Critical Events for Surface Operations 
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6 Summary and Recommendations for Future Work 

The general approach taken to reduce risk of a mission is to design out credible single 
faults where possible; mitigate risk using redundancy in design; plan for residual risk 
through operations procedures and contingencies; and accept risk through waivers. Since 
mission success requires the successful execution of critical events, and failures involving 
critical system functions can lead to mishap, critical events must be understood as a key 
component of risk analysis. 

This report investigates how selected NASA centers deal with critical events as a 
matter of mission design and operations. State of the practice in mission design processes 
and operations procedures for critical events was surveyed, as well as major critical 
events for active missions at three NASA centers: ISS at JSC, EO-1 at GSFC, and MER 
at JPL. 

For these sample missions, specific critical events and their attributes were identified 
from analysis of GO/NO-GO flight procedures, on-board automated fault protection, and 
flight rules. Analysis was conducted on a case-by-case basis, and each critical event was 
defined in terms of GO/NO-GO decisions made under nominal and anomalous scenarios. 
The infonnation gathered by this approach is very domain specific. Since there is little in 
common between the ISS, EO-1, and MER missions, their critical events show little 
overlap. However in a larger sampling of missions with similar mission phases, it is 
expected that critical events will show commonality at the appropriate level of 
abstraction. This will more readily allow comparison of critical events across missions 
and mishaps, to identify recurrent themes and discern trends. 

It is therefore recommended that a larger survey be undertaken in order to identify 
classes of critical events and attributes that are not adapted to a specific mission. This 
survey was just a small beginning in this process. It is also recommended that a more 
systematic method be developed for identification and analysis of critical events across 
missions and mishaps; this could be a classification method, taxonomy, or set of 
guidelines. For instance, any activity involving a shared resource where unavailability of 
that resource impacts mission goals, such as a solid state recorder or downlink 
communications, has the potential for resource conflict and over-subscription. As a 
guideline, this helps to identify such activities as candidate critical events. 

Examination of the procedures at the three NASA centers indicated that processes 
appear to be tailored to the particular applications and needs of the center. There is little 
reuse of the body of knowledge across the agency to take advantage of overlap and 
commonality where it does exist. A long-tenn goal for further work would be to ensure 
that standard practices, design guidelines, techniques, and operating procedures for 
critical events are developed. 

Short-term steps could be to send a questionnaire out to participating centers (JSC, 
GSFC, and JPL), to assess more fully their practices for handling of critical events, and to 
engage the centers in the assessment. The survey could include questions that help 
detennine whether a critical event is a hard or soft critical event, mission critical or 
mission enabling, and whether sufficient data is monitored at the pre-commit to ensure 
coverage of the critical event. Additional work could be to flow-chart the process at each 
center, following a critical event and tracing it through the design process, operations 
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procedures, and anomaly resolution procedures. The charts from each center could then 
be compared to seek a basis for standardization. 

7 Conclusions on the Role of Critical Events in Design and Operations 

Although this report targeted active missions, critical events may also be analyzed early 
in the mission concept phase, even before traditional methods such as an integrated risk 
assessment (IRA) are applicable. This is due to the fact that the critical event can be 
meaningfully expressed at a higher level of abstraction. An IRA focuses on hazards or 
failure modes for each component, with cause and effect, criticality, and corrective 
action, and requires design to be far enough advanced for component selection to have 
been made. The scope of critical event analysis is also wider than that of an IRA, as both 
nominal and anomalous operations are examined. 

The importance of early analysis of critical events and its link to operations has 
further implications. Long-tenn operations costs and risks in the ISS program were 
impacted by lack of systems integration between flight/ground design and operations, and 
lack of involvement of operations in early design [15]. The concept of the critical event 
penneates the system life cycle, the thread running through system specification to the 
implementing operations procedures and flight rules that monitor and verify that critical 
events take place as planned. Traditional systems engineering processes may be used to 
define system functional requirements for critical events, as well as for verification and 
validation of coverage and traceability of critical events from mission design through 
operations. Operators and designers equally understand the importance of critical events; 
critical events may provide the common ground to better link the design phase to mission 
operations, and ensure that operations needs are taken into consideration early in the 
design. 

Critical event analysis reduces risk by providing guidance to designers, operators, 
and program managers as to the requirements for sensing, monitoring, telemetry, and data 
collection, to help ensure that adequate observation and decision-making capabilities are 
in place during mission-critical events. There is a natural tension between engineering 
staff who want more data and systems for improved reliability and performance, and 
program managers who want to limit cost and schedule. As an example, in order to 
manage the Mars Polar Lander program within the established cost constraints, the 
decision was made not to expend any resources on efforts that did not directly contribute 
to landing safely on the surface of Mars. On that basis, no telemetry was provided for 
Entry, Descent, and Landing. As a result, the MPL mishap occurred in a telemetry 
blackout, and the incident had to be painfully reconstructed without data from the 
spacecraft. 

An understanding of critical events may help prioritize mission design and 
operations decisions that trade off cost and schedule against risk and technical resources. 
This prioritization assists in the optimal allocation of limited resources and establishing 
safe margins for critical perfonnance parameters such as mass, power, propellant, 
telemetry bandwidth, CPU speed, control cycle rates, interrupt rates and durations, 
memory and cache sizes, etc. 

Trends suggesting that unintentional subsystem interactions have become a 
significant cause of mishaps since 1997 have been identified [11]. The potential for 
mishaps involving subsystem interactions is supported by the small sampling in this 
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report; all of the identified critical events for JSC’s rendezvous and docking involve 
interactions of multiple subsystems, of the Shuttle and Station systems. For GSFC, many 
of the identified critical events cross subsystem boundaries, as indicated in Table 3. For 
JPL rovers, critical events cross subsystem boundaries in most cases. Critical events 
provide a means of analyzing subsystem interactions and generating or validating 
subsystem interface requirements, such as expected subsystem interface parameter values 
under various critical operating conditions (e.g., GO/NO-GO, nominal/anomalous). This 
has greatest impact during early design, and results may later be flowed down to detailed 
subsystem interface control documents. 

The long-tenn vision for mission operations includes autonomous operations and 
health management of critical events. Remote missions would benefit most from 
autonomous health management of critical events, for local oversight when it is needed 
most. Mission operations can be conducted by JSC in real time, since Shuttle and Station 
are in low-earth orbit and communications delays are on the order of seconds or less. JPL 
must pre-plan and carefully verify command sequences before upload, as the 20-minute 
Mars communication delay precludes real-time remote mission operations. GSFC 
operations are the least constrained, in that critical events are not human rated and do not 
have significant communication delays in Earth orbit. As this environment is relatively 
low risk, GSFC may be open to autonomous critical events, as is currently demonstrated 
by the Autonomous Sciencecraft Experiment (ASE)/Livingstone 2 software that is 
autonomously monitoring and operating EO-1 [16, 17]. Once autonomous operations are 
proven for critical events in low-earth orbit on an unmanned spacecraft, this can be 
extended to critical events for more challenging and remote missions. 
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10 Appendix A - JSC Rendezvous Operations Procedures 

Flight Rule C2-56: 

SHUTTLE GO/NO GO FOR DOCKED OPERATIONS [RC] 

A. IN ORDER TO BE GO TO CONTINUE DOCKED OPERATIONS, 

SHUTTLE PROPELLANT MUST BE AVAILABLE TO COVER THE 
FOLLOWING: ©[011801-7369] 

1 . SHUTTLE EMERGENCY UNDOCKING AND SEPARATION PER 
RULE { C4 - 152 } , SHUTTLE/SOYUZ EMERGENCY UNDOCKING 
AND SEPARATION (TBV) [RC] . 

2 . PROPELLANT REQUIRED FOR ORBITER MAINTENANCE 
(ATTITUDE CONTROL -ZLV -XVV OR THERMAL PROTECT 
ATTITUDE IF REQUIRED, 1 DEGREE VRCS , ONE IMU 
ALIGN/DAY) FOR 1 DAY. 

3. DEORBIT REDLINES : 

a. OMS DEORBIT REDLINE (REF RULE {A6-303A}, OMS 
REDLINES [CIL] ) 

b. FRCS DEORBIT REDLINE (REF RULE {A6-304A}, 
FORWARD RCS REDLINES) 

c. ARCS ENTRY REDLINE (REF RULE {A6-305}, AFT RCS 
REDLINES) 

B. IF SUFFICIENT PROPELLANT IS NOT AVAILABLE TO BE GO TO 
CONTINUE DOCKED OPERATIONS, UNDOCKING AT THE EARLIEST 
POSSIBLE OPPORTUNITY IS REQUIRED. 


The ability to execute an immediate emergency undocking and separation, and subsequent 
deorbit to a Next Primary Landing Site (NPLS), is required in order to safely terminate the 
mission in the event of an emergency. This requires that sufficient propellant must be available 
post-undocking for attitude control until the next PLS deorbit opportunity (which could be up to 
24 hours away). Note that if execution of the emergency undock and separation will increase the 
size of the deorbit burn, that increased delta V must be protected. ©[011801-7369 ] 

FLIGHT/STAGE EFFECTIVITY: ALL FLIGHTS 
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Flight Rule C2-101: 

ISS GO/NO-GO MA TRIX FOR RENDEZVOUS [he] [RC] ®[033105- 
6222D] 


SYSTEM 

FAILURE 

NC 

Tl 

PROX 

RPM [36] 

R < 

R < 

R < 

DOCK 



FINAL 


OPS 


400 FT 

250 FT 

170 FT 


ISS 

RS ARRAYS NOT IN REQUIRED POSITION FOR 

GO 

GO 

GO 

GO 

GO 


DLY [2] 

GO [2] 


DOCKING 










USOS ARRAYS NOT IN REQUIRED POSITION 

GO 

GO 

GO 

GO 

DLY [2] 


GO [2] 

GO [2] 


FOR DOCKING 










ISS IS NOT IN DOCKING ATTITUDE 

GO 

GO 

GO [3] 

NO-GO [26] 

ABT [1] 


ABT [1] 

ABT [1] 


ISS TRACKING LIGHT 

GO 

GO [3] 

GO 

GO 

GO 


GO 

GO 


ISS COMMUNICATION WITH GROUND 

GO 

Tl DLY 

ABT [18] 

GO 

ABT [18] 


ABT [18] 

ABT [18] 


ISS COMMUNICATION WITH ORBITER 

GO 

GO 

GO 

GO 

GO 


GO 

GO 


ISS TRANSLATIONAL JETS NOT INHIBITED 

GO 

Tl DLY 

ABT [19] 

NO-GO [19] 

ABT [19] 


ABT [19] 

ABT [19] 


ISS SYSTEM FAILURE [7] 


Tl DLY 

ABT 

NO-GO 

ABT 


ABT 

ABT 


PRIMARY C&C MDM 


Tl DLY [23] 

GO 

GO 

DLY [23] 


DLY [23] 

DLY [23] 


PRIMARY GNC MDM (WHILE UNDER RS 
THRUSTER CONTROL) 


GO 

GO 

GO 

GO 


GO 

GO 


PRIMARY INT MDM 


GO 

GO 

GO 

GO [21] 


GO [21] 

GO [21] 


LAI AND LA2 MDM’S 


GO 

GO 

GO 

GO [21] 


GO [21] 

GO [21] 


LOSS OF ATTITUDE CONTROL 

GO 

Tl DLY (22) 

GO 

NO-GO [27] 

ABT [24] 


ABT [24] 

ABT [24] 


DIGITAL STILL CAMERA (ALL ISS 400/800 MMl) 


GO 

GO 

NO-GO 

GO 


GO 

GO 

PROP/RCS 

VRCS 

GO 

GO 

GO 

GO 

GO 

GO 

GO 

GO 


LAST AFT FIRING JET (+X) 

GO 

Tl DLY [8] 

ABT [32] 

NO-GO [28] 

ABT [32] 

ABT [4] 

ABT [4] 

ABT [4] 


LAST FORWARD FIRING JET (-X) 

GO 

Tl DLY [8] 

ABT [32] 

NO-GO [28] 

ABT [32] 

ABT [4] 

ABT [4] 

ABT [4] 


LAST FORWARD OR AFT LEFT FIRING JET (+Y) 

GO 

Tl DLY [8] 

GO [37] 

NO-GO [28] 

GO [37] 

ABT [4] 

ABT [4] 

ABT [4] 


LAST FORWARD OR AFT RIGHT FIRING JET (-Y) 

GO 

Tl DLY [8] 

GO [37] 

NO-GO [28] 

GO [37] 

ABT [4] 

ABT [4] 

ABT [4] 


LAST UP FIRING JET IN FORWARD OR EITHER 

GO 

Tl DLY [8] 

GO 

GO 

GO 

ABT [4] 

ABT [4] 

ABT [4] 


AFT (+NZ) 

2 FORWARD FIRING JETS (DEGRADED -X, +LZ) 

GO 

GO [5] 

GO [5] 

GO [5] 

GO [5] 

GO [5] 

GO [5] 

GO [5] 


LAST AFT-FIRING JET IN EITHER POD 

GO 

GO [5] 

GO [5] 

NO-GO [39] 

GO [5] 

GO [5] 

GO [5] 

GO [5] 


(DEGRADED +X, +LZ) 










LAST DOWN FIRING JET ON EITHER SIDE OF 

GO 

Tl DLY [8] 

ABT [38] 

[33] 

ABT [38] 

ABT [4, 6] 

ABT [4, 6] 

ABT [4, 6] 


FORWARD (+LZ PITCH AND PCT) 










LAST DOWN FIRING JET IN EITHER AFT POD 

GO 

Tl DLY [8] 

GO [29] 

NO-GO[34] 

GO [29] 

ABT [6] 

ABT [6] 

ABT [6] 


(+LZ ROLL AND PCT) 










ANY SINGLE FWD DOWN FIRING JET OR ANY 2 

GO 

GO 

GO 

NO-GO [38] 

GO 

GO 

GO 

GO 


DOWN FIRING JETS IN EITHER AFT POD 









GNC 










IMU’S 

2 1 

GO 

TI-DLY [8] 

GO [35] 

NO-GO [30] 

GO [35] 

ABT 

ABT 

ABT 

CAMERAS 

BOTH CENTERLINE/KEEL CAMERAS FAIL 

GO 

GO 

GO 

GO [40] 

GO 

ABT 

ABT 

ABT 

TCS/HHL 

ALL UNITS FAILED 

GO 

GO 

GO 

NO-GO [31] 

GO 

GO 

ABT [20] 

ABT [20] 

CAMERA A & D 

BOTH UNITS FAILED 

GO 

GO 

GO 

GO 

GO 

GO 

GO 

ABT [20] 

STAR TRACKER 

2 i 

GO 

GO 

GO 

GO 

GO 

GO 

GO 

GO 

RNDZ RADAR 

1 1 

GO 

GO 

GO (IF VIS) 

GO 

GO 

GO 

GO 

GO 

COAS 

1 i 

GO 

GO 

GO 

GO 

GO 

GO 

GO 

GO 

ANGULAR ALIGN 

ANGULAR ALIGNMENT CANNOT BE VERIFIED 

GO 

GO 

GO 

GO 

GO 

GO 

GO 

ABT 

AFT THC 

3 ± X 4- OR 3 ± Y 4- OR 2 -Z 4- 

GO 

TI-DLY [8] 

ABT 

NO-GO 

ABT 

ABT 

ABT 

ABT 

CONTACTS 










FWD AND AFT 

2 -Z FWD AND 2 -Z AFT 4- 

GO [11] 

GO [11] 

GO 

GO 

GO 

ABT 

ABT 

ABT 

THC CONTACTS 

4 +z 4- 

GO 

TI-DLY [8] 

GO 

GO 

GO 

ABT [12] 

ABT [12] 

ABT [12] 

DPS 










1 OF 3 GNC GPC’S 

1 i 

GO [9] 

GO [9] 

GO [9] 

GO [9] 

GO [9] 

GO [9] 

GO [9] 

GO [9] 

1 OF 2 GNC GPC’S 

1 1 

GO 

TI-DLY 

GO 

NO-GO [30] 

GO 

ABT [10] 

ABT [10] 

ABT [10] 

ANY GPC’S 

2 i 

GO [15] 

ABT [14] 

ABT [14] 

NO-GO [14] 

ABT [14] 

ABT [14] 

ABT [14] 

ABT [14] 

MDM (FF, FA, PL) 

1 4- 

GO 

GO 

GO 

GO [41] 

GO 

GO 

GO 

GO 

SM GPC 

1 1 

GO [16] 

GO [16] 

GO [16] 

GO [16] 

GO [16] 

GO [16] 

GO [16] 

GO [16] 


©[062497-601 9A] ©[040998-6450] ®[ED 
4790B] 

©[121902-5854] ©[042403-5929] ©[033105-6222D] 


] ®[1 02398-671 8C] ©[092800-7237] ©[110900-7370 


©[082301- 


THIS RULE CONTINUED ON NEXT PAGE 
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C2-101 ISS GO/NO-GO MATRIX FOR RENDEZVOUS [HC] [RC] 

(CONTINUED) 


NOTES: 

[1] THE CORRIDOR APPROACH IS DESIGNED TO ENSURE PROXIMITY OPERATIONS ARE WITHIN THE 
LOADS DATABASE AND THAT TCS TARGETS ARE AVAILABLE. TO PROTECT THE RUSSIAN SOLAR 
ARRAYS, THE ORBITER CANNOT PROCEED CLOSER THAN 170 FT WITHOUT THE ISS BEING IN 
DOCKING ATTITUDE. STATIONKEEP AT OR BACKOUT TO 170 FT AND AWAIT THE ATTITUDE 
MANEUVER. TO PROTECT DEPLOYED U.S. SOLAR ARRAYS, THE ORBITER CANNOT PROCEED 
CLOSER THAN 400 FT. STATIONKEEP AT OR BACKOUT TO 400 FT AND AWAIT THE ATTITUDE 
MANEUVER IF U.S. SOLAR ARRAYS ARE DEPLOYED. WHEN U.S. SOLAR ARRAYS ARE DEPLOYED 
OUTBOARD OF S3 OR P3, THE U.S. CONSTRAINT IS EXPECTED TO INCREASE TO 600 FT. THIS WILL 
BE ASSESSED BEFORE 12A.1. @[062497-601 9A ] @[102398-67180] @[110900-7370] @[121902-5854] 

[2] GO IF SHUTTLE LOW Z IS AVAILABLE. @[08230 1-4790B] 

WITHOUT LOW Z: 

DELAY APPROACH WITHIN 170 FT UP TO AN ORBIT IF POSSIBLE TO POSITION RUSSIAN SOLAR 
ARRAYS. 

DELAY APPROACH WITHIN 400 FT UP TO AN ORBIT IF POSSIBLE TO POSITION U.S. SOLAR ARRAYS. 
OTHERWISE, PROCEED CLOSER WITHOUT ARRAYS BEING FEATHERED OR CONFIRMED NOT TO BE IN 
A KEEP-OUT ZONE. 

REF RULES {C2-104}, ISS SYSTEM MANAGEMENT FOR APPROACH AND DOCKING [HC] [RC], AND {C2- 
109}, RNDZ/PROX OPS LOW Z/NORM Z MANAGEMENT [RC], @[082301 -4790B] 

[3] FOR FLIGHTS STARTING WITH 4A, IF THE TRACKING LIGHT FAILS, THEN THE ORBITER STAR 
TRACKERS WILL NOT BE AVAILABLE AS AN OPTIONAL SENSOR DURING THE RENDEZVOUS. THE USE 
OF THE STAR TRACKERS WITH THE TRACKING LIGHT ALSO REQUIRES THAT THE ISS IS IN AN 
ATTITUDE THAT ALLOWS USE OF THE TRACKING LIGHT BY Tl + 28 MINUTES. 

[4] ORBITER WILL NOT PROCEED INSIDE OR CONTINUE INSIDE 250 FT IF CONTROL IS COMPLETELY LOST 
IN ONE AXIS. 

[5] SPECIAL CONDITIONS MUST BE MET TO CONTINUE INSIDE OF 1000 FT WITHOUT LOW Z BRAKING 
ABILITY. NO NORM Z BRAKING IS ALLOWED BETWEEN 1000 FT AND 75 FT. REF RULE {02-109}, 
RNDZ/PROX OPS LOW Z/NORM Z MANAGEMENT [HC] [RC], ®[ED ] 

[6] THE ORBITER CAN PROCEED WITH LOSS OF LOW Z ATTITUDE CONTROL. THE ORBITER SHOULD 
STAY VRCS IF AVAILABLE AND MODE TO NORM Z TAIL ONLY (IF AVAILABLE) AND NORM Z NOSE/TAIL 
OTHERWISE. HOWEVER, THE ORBITER CANNOT ATTEMPT A DOCKING IF POT IS LOST. A GMEM 
OVERWRITE MUST BE IMPLEMENTED BEFORE THE ORBITER IS GO TO ATTEMPT A DOCKING. IF IN A 
“LOSS OF LOW Z ATTITUDE” OR “LOSS OF POT” CASE, THE CONTROL IN THE -Z AND/OR ±Y AXES WILL 
ALREADY BE LOST, SO THE ORBITER WILL BE NO-GO INSIDE OF 250 FT. REF RULE {C2-109}, 
RNDZ/PROX OPS LOW Z/NORM Z MANAGEMENT [HC] [RC], ®[ED ] 

[7] IF ANY ISS SYSTEMS FAIL (SUCH AS MCS, COMM, THERMAL, CDH, ETC.), WHICH WOULD PREVENT A 
SUCCESSFUL DOCKING OR VIOLATE DOCKING CONSTRAINTS, THE RENDEZVOUS WILL BE ABORTED. 
PRIOR TO Tl, A Tl DELAY MAY BE PERFORMED TO ALLOW TIME TO RECOVER THE FAILED SYSTEM. 
POST-TI, THE RENDEZVOUS WILL BE HALTED AT THE NEXT MOST CONVENIENT POINT. REFERENCE: 
HAZARD REPORT ISS-GNC-701-9A. @[121902-5854] ©[033105-6222D] 

[8] GO FOR Tl IF CAPABILITY CAN BE RECOVERED PRIOR TO 250 FT WITHOUT IMPACTING RENDEZVOUS 
OPERATIONS. Tl DELAY MAY BE PERFORMED TO PROVIDE MORE TIME TO EVALUATE THE SYSTEM 
FAILURE AND RECOVERY EFFORTS. @[110900-7370 ] 

[9] WHEN POSSIBLE, RESTRING TO REMAINING TWO GNC GPC’S. A RESTRING IS REQUIRED PRIOR TO 
THE RPM IN ORDER TO REGAIN REQUIRED JET REDUNDANCY. ©[033105-6222D] 

[10] IF RANGE IS LESS THAN 250 FT, BACK OUT TO 250 FT AND RESUME APPROACH WHEN 
RECONFIGURED TO TWO GNC GPC’S. 

[11] INCLUDES STRINGING. IF REDUNDANCY RECOVERABLE PRIOR TO 250 FT. 

[12] GO IF EACH THC HAS ONE CONTACT REMAINING. @[062497-601 9A ] 

[13] RESERVED @[110900-7370] 
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[14] THIS ABORT CRITERIA IS BASED ON THE ASSUMPTION THAT AN SM AND A BFS MACHINE ARE 
REQUIRED AND THEREFORE NOT ENOUGH GPC’S ARE LEFT TO GET REDUNDANT GNC GPC'S. 
WITHOUT REDUNDANT GNC GPC’S, THE ORBITER IS NO-GO TO BURN Tl OR TO PROCEED INSIDE OF 
250 FT SO THERE IS NO REASON TO CONTINUE WITH THE RENDEZVOUS. IF THE SM OR BFS MACHINE 
COULD BE CONVERTED TO A GNC MACHINE, THEN THERE WOULD NOT BE ANY ABORT CRITERIA. 
(ADDITIONALLY, THIS FAILURE INVOKES AN MDF CONDITION ACCORDING TO THE FLIGHT RULES.) 

[15] THIS FAILURE INVOKES AN MDF CONDITION ACCORDING TO THE FLIGHT RULES. ®[1 02398-671 8C] 

[16] WHEN POSSIBLE, GIVE UP 1 OF THE 3 GNC GPC’S AND FORM A NEW SM GPC. ®[1 02398-671 8C] 

[17] RESERVED 

[18] WHILE AN ISS CREW IS ON-BOARD, RENDEZVOUS MAY PROCEED IF THE SHUTTLE AND ISS CREW 
HAVE VOICE COMMUNICATION AND CAN CONFIRM ISS SYSTEMS IN THE DOCK-READY 
CONFIGURATION. REF RULE {C2-106}, COMMUNICATIONS COVERAGE REQUIREMENTS DURING 
DOCKING OF SHUTTLE [HC] [RC], IF THERE IS NO CREW ON-BOARD AND THE ABILITY FOR THE 
GROUND TO COMMUNICATE IS LOST, THE RENDEZVOUS WILL BE ABORTED. PRIOR TO Tl, A Tl DELAY 
COULD BE PERFORMED TO ALLOW TIME TO TRY TO RECOVER GROUND COMMUNICATION. POST-TI, 
THE RENDEZVOUS WILL BE HALTED AT THE NEXT MOST CONVENIENT POINT. @[121902-5854 ] 

[19] THE TRANSLATIONAL JETS ON THE ISS MUST BE INHIBITED TO PREVENT OVERPRESSURE OR 
THERMAL DAMAGE TO THE SHUTTLE DUE TO POTENTIAL ISS JET EXHAUST PLUME. IF THE 
TRANSLATIONAL JETS ON THE ISS CANNOT BE INHIBITED, THEN THE RENDEZVOUS WILL BE 
ABORTED. PRIOR TO Tl, A Tl DELAY COULD BE PERFORMED TO ALLOW TIME TO TRY TO INHIBIT THE 
JETS. POST-TI, THE RENDEZVOUS WILL BE HALTED PRIOR TO ENTERING PROXIMITY OPERATIONS. 

[20] TO CONTINUE THE APPROACH (BETWEEN 170 FT AND 10 FT) WITH NO TCS/HHL UNITS OR TO 
PROCEED INSIDE 10 FT WITHOUT CAMERA A OR D WILL MEAN APPROACHING OUTSIDE THE BOUNDS 
OF PLUME, PROP AND CONTACT CONDITIONS ANALYSIS. CONSIDERATION CAN BE GIVEN TO 
CONTINUING THE APPROACH WITH THE ACCEPTANCE OF POTENTIALLY SEVERE IMPACTS TO PLUME 
LOADING ON THE STATION APPENDAGES, SHUTTLE PROPELLANT MARGINS, AND CONTACT 
CONDITIONS. ®[1 02398-671 8C] ©[110900-7370] 

[21] IF ACS AUTO-MODING SOFTWARE/LIGHTS CANNOT BE CONFIGURED TO SUPPORT AUTOMATIC 
MODING AT CONTACT, OR IF PRIMARY INT MDM FAILS, OR IF BOTH LAI AND LA2 MDM’S FAIL, 
CONTINUE APPROACH WITH ISS CREW DESIGNATED PRIME AND MCC-H/M DESIGNATED BACKUP FOR 
COMMANDING ISS TO FREE DRIFT UPON “CAPTURE CONFIRMED.” ©[082301 -4790B] 

[22] “GO FOR Tl” REQUIREMENTS DICTATE ISS MUST BE IN A KNOWN CONFIGURATION CAPABLE OF 
ACHIEVING THE DOCKING ATTITUDE WITH LVLH RATES OF 0.04 DEG/SEC PER AXIS OR LESS. 

[23] C&C MDM FAILURE TAKES DOWN ALL AUTOMATIC MODING (OF BOTH USOS AND RS) AND MANUAL 
USOS COMMANDING TO FREE DRIFT, AS WELL AS ALL USOS COMMAND AND TELEMETRY. IN THE 
CASE WHERE RUSSIAN MANUAL MODING IS REQUIRED, THE CREW SHALL HAVE ACCESS TO A 
RUSSIAN LAPTOP OR ISS MAY BE OVER A RUSSIAN GROUND SITE. REFER TO RULE {C2-104}, ISS 
SYSTEM MANAGEMENT FOR APPROACH AND DOCKING [HC] [RC], AND RULE {C2-106}, 
COMMUNICATIONS COVERAGE REQUIREMENTS DURING DOCKING OF SHUTTLE [HC] [RC], A C&C MDM 
SHOULD AUTOMATICALLY BE RECOVERED WITHIN 5 SECONDS, WHICH WILL PROVIDE TELEMETRY 
AND GROUND COMMANDING. THE ISS CREW WOULD HAVE TO RECONNECT THE PCS FOR COMMAND 
AND TELEMETRY CAPABILITY. 

[24] THE ORBITER WILL PERFORM A CORRIDOR BACKOUT TO 400 FT ON +VBAR TO MITIGATE SHUTTLE 
PLUME AND COLLISION CONCERNS IF ISS DRIFTS OUT OF ATTITUDE. THE ORBITER MAY CONTINUE IN 
FROM 400 FT ONCE ISS HAS ASSUMED ATTITUDE CONTROL AND IS BACK IN THE DOCKING ATTITUDE. 
REFERENCE: HAZARD REPORT ISS-GNC-701-9A. @[121902-5854] ©[033105-6222D] 

[25] GO IF ATTITUDE CONTROL IS HANDED OVER TO THE SM. ACS MODING WILL STILL FUNCTION. IF TIME 
ALLOWS, PREPARE FOR MCC-M BACKUP COMMAND. ©[082301 -4790B] 

[26] RELATIVELY SMALL EXCURSIONS FROM THE DOCKING ATTITUDE COULD OBSCURE THE VIEW FROM 
THE ISS WINDOW. IN ADDITION, PLUME LOADS ON ISS HAVE ONLY BEEN ANALYZED FOR THE 
DOCKING ATTITUDE. 

[27] CONTINUE TO 400 FT ON VBAR TO AWAIT TROUBLESHOOTING. ©[033105-6222D] 
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[28] POSITIVE CONTROL IS REQUIRED IN EACH AXIS IN ORDER TO SET UP THE INITIAL CONDITIONS FOR 
THE RPM. ©[033105-6222D] 

[29] LOSS OF PRCS LOW Z ROLL CONTROL. GO AS LONG AS VERNS ARE AVAILABLE. 

[30] CRITICAL VEHICLE CONTROL SYSTEMS MUST BE REDUNDANT TO SAFELY PERFORM THE RPM. 

[31] USE OF TCS OR HHL IS REQUIRED TO MEET THE RANGE AND RANGE RATE CONDITIONS SPECIFIED 
FOR STARTING THE PITCH MANEUVER. ATTEMPTING THE MANEUVER WITHOUT MEETING THESE 
CONDITIONS COULD ALLOW LARGE TRAJECTORY DISPERSIONS TO BUILD DURING THE MANEUVER. 
RECOVERY FROM THESE DISPERSIONS COULD BE PROPELLANT-EXPENSIVE, AND WOULD BE 
FURTHER COMPLICATED BY THE UNAVAILABILITY OF THE TCS AND HHL SENSORS. SINCE HHL RAW 
RANGE RATE AT THE RPM RANGE HAS BEEN SHOWN TO BE HIGHLY DEPENDENT ON OPERATOR 
TECHNIQUES, CONSECUTIVE RANGE MARKS SHOULD BE USED TO ESTIMATE RANGE RATE. THE 
RPOP HHL/DT FUNCTION IS PREFERRED FOR THIS METHOD. (REFERENCE ORBIT FLIGHT 
TECHNIQUES PANEL #217, JANUARY 28, 2005.) 

[32] BOTH ±X TRANSLATIONS ARE REQUIRED TO STABILIZE ON THE +RBAR, TO START AND STOP THE 
TWICE ORBITAL RATE VBAR APPROACH (TORVA), AND TO MAINTAIN THE VBAR. 

[33] THE RPM IS ALREADY NO-GO FOR LOSS OF THE FIRST FORWARD DOWN-FIRING JET (SEE NOTE [38]). 

[34] IF ALL DOWN-FIRING JETS IN THE SAME AFT POD ARE FAILED, THERE IS NOT ADEQUATE PRCS 
CONTROL AUTHORITY TO NULL THE PITCH RATE. THE TORVA IS FLYABLE IN LOW Z IN THIS CASE 
ONLY IF VERN JETS ARE AVAILABLE. OTHERWISE, ROLL CONTROL IS COMPLETELY LOST. 

[35] ONCE Tl IS EXECUTED, A LOSS OF SYSTEMS REDUNDANCY IS NOT CAUSE TO ABORT/BREAKOUT IF 
THE SYSTEM CAN BE RECOVERED AT THE NEXT CONVENIENT HOLDING POINT (ALTHOUGH CERTAIN 
REDUNDANCY REQUIREMENTS EXIST FOR THE RPM). 

[36] THIS COLUMN DEFINES THE GO/NO-GO CRITERIA FOR STARTING THE RPM. 

[37] ALTHOUGH ±Y CAPABILITY IS LOST, LARGE Y EXCURSIONS ARE NOT EXPECTED DURING THIS 
TIMEFRAME. ALSO, INCREASED CLOSURE FROM CROSS-COUPLING WOULD NOT BE SIGNIFICANT IN 
THIS JET CONFIGURATION. 

[38] WITH TWO FORWARD DOWN-FIRING JETS LOST ON ONE SIDE, ±Y AND LOW Z BRAKING CAPABILITY IS 
LOST. LARGE CLOSURE MAY DEVELOP DUE TO DEGRADED PRCS LOW Z ATTITUDE CONTROL. 
STARTING THE RPM WILL CAUSE A LARGE CLOSING RATE TOWARD ISS THAT WILL FORCE A 
BREAKOUT FROM THE RENDEZVOUS. WHILE THIS BREAKOUT TRAJECTORY PROVIDES ADEQUATE 
CLEARANCE BETWEEN THE ORBITER AND THE ISS (> 170 FT), THERE MAY NOT BE ENOUGH 
PROPELLANT TO PERFORM A RE-RENDEZVOUS. TO PRECLUDE THE POSSIBILITY OF A BREAKOUT, 
REDUNDANT FORWARD DOWN-FIRING JETS ARE REQUIRED FOR THE RPM. (REFERENCE ORBIT 
FLIGHT TECHNIQUES PANEL #216, NOVEMBER 19, 2004.) ®[ED ] 

FAILURE OF THE REMAINING DOWN-FIRING AFT JET DURING THE RPM WOULD RESULT IN A LOSS OF 
LOW Z PRCS PITCH CONTROL (SEE NOTE [34]). 

[39] PERFORMING THE RPM WITH ONLY ONE +X JET COULD COMPLICATE THE TRANSITION FROM THE 
RPM INTO THE TORVA. 

[40] CAMERA A OR D CAN BE ALIGNED ALONG THE -Z AXIS TO BE USED AS A CENTERLINE CAMERA 
SUBSTITUTE FOR SETTING UP THE RPM INITIAL CONDITIONS. 

[41] THE OTHER SYSTEMS PORTIONS OF THE TABLE SHOULD BE CONSULTED TO DETERMINE 
RENDEZVOUS IMPACTS FROM LOSS OF SYSTEMS ASSOCIATED WITH THE AFFECTED MDM. 


Reference: Hazard Report ISS-COLL-1 003-1 1 A, Hazards during Proximity Operations. 

®[033105-6222D] 

FLIGHT/STAGE EFFECTIVITY: 11A AND SUBS ®[ED ] 
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Flight Rule C2-104: 

ISS system management for approach and docking [HC] [RC] ®[052401- 
7518 ] 

A. ISS APPENDAGE CONFIGURATION: ©[110900-7370] 

1. NOMINALLY, THE P6 4B SOLAR ARRAY WILL BE FIXED AT 
210 DEGREES AND THE P6 2B SOLAR ARRAY WILL BE FIXED 
AT 150 DEGREES FOR ORBITER APPROACH WITHIN 400 
FEET. THE BGA' S WILL NOT BE LATCHED AND THE DRIVE 
MOTORS WILL REMAIN POWERED WITH THE BGA MODE SET TO 
DIRECTED POSITION. ©[092701-4792D] 

This Rule defines the P6 array positions for approach and docking. Boeing-ISS loads, and 
thermal and control analyses have shown there are no requirements to lock the BGA ’s for 
dockings to the PMA2 on the Lab Forward CBM. 

2. NOMINALLY, THE FGB AND SM SOLAR ARRAYS WILL BE 
FIXED IN SUN ZONE 1 OR 9 FOR ORBITER APPROACH 
WITHIN 170 FEET. 


This Rule defines the SM and FGB array positions for approach and docking. 

3. THE SHUTTLE WILL DELAY APPROACH UP TO ONE ORBIT, 
PROPELLANT ALLOWING, STATIONKEEPING TO ALLOW ISS 
SOLAR ARRAYS TO BE ORIENTED TO THE POSITIONS 
DEFINED ABOVE. IF THE 2B OR 4B ARRAY IS WITHIN A 
RANGE OF +5 DEG FROM WHAT IS DEFINED IN PARAGRAPH 1 
ABOVE, DOCKING MAY CONTINUE WITHOUT DELAY. 


The ±5 deg angle range will only be used if the array cannot be positioned nominally as a result 
of a BGA positioning problem. Any position between the ±5 deg range is sufficient to protect the 
array against departure loads. 

4. IF THE USOS OR RS ARRAYS CANNOT BE ORIENTED IN THE 
POSITIONS DEFINED ABOVE, APPROACH AND DOCKING MAY 
PROCEED WITH OR WITHOUT LOW Z BRAKING. NO NORM Z 
BRAKING IS ALLOWED BETWEEN 1000 FT AND 75 FT. 


There are no loads or thermal keepout zones for dockings to the PMA2 on the Lab Forward CBM. 
Special conditions must be met to continue inside of 1000 ft without Low Z braking ability. 
Reference Rule {C2-109J, RNDZ/PROX OPS LOW Z/NORM Z MANAGEMENT [HCJ [RC] . 

©[092701 -4792D] ®[ED ] 
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Loads analyses indicate shuttle plume loads within 170 feet could exceed Russian solar array 
load limits and, within 400 feet, could exceed U.S. solar array load limits if the arrays are not 
locked. It should be noted that if the U.S. solar arrays are not feathered, a TORVA from the 
+Rbar during approach should be initiated by 600 feet to ensure the orbiter is no closer than 400 
feet at Vbar arrival. @[032901-7485] 

Reference: Hazard Report 1SS-MCH- 109. ©[092701-4792D] 

FLIGHT/STAGE EFFECTIVITY: 2 A THROUGH 12A 

B. STATION -ORB I TER ATTITUDE CONTROL SYSTEM MODING AT 

DOCKING 

1. AT LEAST ONE COMMAND SOURCE SHALL BE AVAILABLE TO 
MODE THE STATION INTO FREE DRIFT. @[032901-7485] 

2. THE LIST OF COMMAND SOURCES INCLUDES THE FOLLOWING 
IN ORDER OF PRIORITY: 


PRIORITY 

COMMAND SOURCE 

1 . 

AUTOMATIC ACS MODING IN THE CCS 

2. 

ISS CREW 

3. 

GROUND (MCC-H OR MCC-M) 

@[032901-7485] 

® 

[092701 -4792D] 


3. IF THE ISS IS NOT IN FREE DRIFT 20 SECONDS AFTER 
THE ORBITER CREW CALL OF CAPTURE CONFIRMED, ANY 
BACKUP COMMAND SOURCE SHALL COMMAND THE ISS TO FREE 
DRIFT. @[302901-7485] @[121902-5855] 

The automatic ACS moding is the first priority command source. The automatic ACS moding 
shall be considered a single, redundant command source, since the ACS moding status is not 
checkpointed to the backup C&C MDM. The highest priority available command source is 
considered the primary command source. The ISS crew is higher priority than the ground to 
protect for a loss of communication. 

For the case of the Sendee Module in attitude control and MCC-M or ISS crew needing to 
command the ISS to free drift, the ISS crew shall send the Russian command that is an imitation 
of the arrival event and completes the docking cyclogram. MCC-M commanding may go through 
U.S. assets, otherwise docking over a Russian Ground Site may be considered. Reference Rule 
{ C2-106 }, COMMUNICATIONS COVERAGE REQUIREMENTS DURING DOCKING OF 

SHUTTLE [HC] [RC] . ©[092701-4792D] @[302901-7485] @[121902-5855] 
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The 20-second delay will allow ample time to evaluate the success of the primary command 
source and will still provide time for the manual command to be executed. The 20 seconds 
provides sufficient time for the docking mechanism signals to reach the C&C MDM, internal 
processing and commanding to the U.S. GNC MDM and RS TC, and telemetry feedback to the 
operator. The 20-second delay is also due to MCC-M’s concern that problems may occur if 
commands are received simultaneously from more than one of the several sources. If ACS 
Moding is not expected to operate due to failures such as an INT MDM at Dock minus 5 minutes, 
either LA MDM ’s, or Node MDM ’s out of sync, it is not necessary to wait 20 seconds. @[302901 - 
7485] @[121902-5855] 

4. IF THE ORBITER CREW HAS NOT RECEIVED POSITIVE 

CONFIRMATION OF ISS FREE DRIFT BEFORE CAPTURE +65 
SECONDS, THEN THE ORBITER CREW WILL OPEN THE LATCHES 
AND PERFORM THE FAILED CAPTURE PROCEDURE. POSITIVE 
CONFIRMATION CAN COME FROM ANY OF THE FOLLOWING: 

a. ISS CREW 

b. ORBITER CREW, BASED ON THE FLASHING LED'S, OR 
FROM THE ARR/DPRTR MODING SPEC 

C. MCC-H @[032901-7485] 

d. MCC-M, IF THE SERVICE MODULE WAS IN CONTROL 
(CALL RELAYED VIA MCC-H) 

If the ISS has not moded to free drift within 65 seconds of capture, the docking mechanism load 
limits may be exceeded. Reference ES/J. Dagen,for 4 A and subs. 

If the LED is steady on, then the station is in attitude control. If the LED is flashing, then the 
station is in free drift. Failures exist that would prevent the LED from flashing. These failures 
would leave the LED ’s either in a powered-off state or in a steady-on state. There is no failure 
that could cause the LED ’s to falsely indicate free drift (per SPN 285). @[032901-7485 ] @[121902- 
5855 ] 

Reference: Hazard Report ISS-MCH- 109. ©[092701-4792D] 

FLIGHT/STAGE EFFECTIVITY: 2A THROUGH 12A ®[ED ] 
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DOCKING [HC] [RC] (CONTINUED) 

C. THE ISS KU-BAND SYSTEM SHALL BE OPERATED IN AUTOTRACK 
MODE WITH THE ANTENNA "SHUTTLE MASK" ENABLED BY RANGE = 
TBD METERS. ©[110900-7370] 

Reference: Hazard Report ISS-MCH- 109. ©[092701-4792D] 

FLIGHT/STAGE EFFECTIVITY: ALL FLIGHTS 

D. SOLAR ARRAY SUN TRACKING SHALL BE RESUMED WHEN CAPTURE 
IS CONFIRMED AND ISS IS IN FREE DRIFT. 


After capture and ISS modes to free drift, the mated stack is in a safe configuration and a 
subsequent separation is unlikely. Therefore, sun tracking will be initiated as soon as possible to 
allow ISS to recover from the rendezvous power down. ®[l 1 0900-7370 ] 

E. REFER TO RULE {B2-19}, U.S. LAB WINDOW OPERATIONAL 
CONSTRAINTS, FOR MANAGEMENT OF THE LAB SHUTTER DURING 
SHUTTLE DOCKING. 

F. SSRMS SHALL BE IN A PRE -ANALYZED DOCKING CONFIGURATION. 
©[092701 -4792D] 

FLIGHT/STAGE EFFECTIVITY: ALL FLIGHTS 
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Flight Rule C2-105: 

Shuttle SENSOR REQUIREMENTS for ISS prox ops [RC] ®[CR 4885 ] 
®[102398-6753A] ®[ED ] ® [110900-7370 ] 

A. FOR ISS FINAL APPROACH AND DOCKING OPERATIONS, THE 

FOLLOWING SENSORS ARE REQUIRED TO ENSURE THAT DOCKING 
CAN BE ACCOMPLISHED WITHIN THE BOUNDS OF ISS 
STRUCTURAL LOAD LIMITS, THE SHUTTLE APPROACH 
PROPELLANT BUDGET, AND THE DOCKING WINDOW: 

A TRAJECTORY CONTROL SENSOR (TCS) OR HAND-HELD LIDAR 
(HHL) , AND 

A CENTERLINE CAMERA, AND 

A PAYLOAD BAY CAMERA WITH AN ASSOCIATED MONITOR OVERLAY 
TO BE USED FOR RANGE/RANGE RATE DETERMINATION 

Parametric database analysis has shown that successful docking can be consistently achieved 
with the use of TCS or HHL in combination with a centerline camera and payload bay bulkhead 
camera. Without a centerline camera, proper lateral and angular alignment to ensure a 
successful docking cannot be guaranteed. Without a TCS or HHL, the proper range/range rate 
profile and approach timing cannot be flown. Use of a payload bay camera with an 
unobstructed view of the docking interface (typically camera A or D) in conjunction with a 
monitor overlay is required in order to achieve the specified closing rate during the last few feet 
of approach given the data latency associated with using either TCS or HHL in conjunction with 
RPOP. Additionally, TCS reflector obscuration and HHL minimum range constraints may make 
these sensors unusable the last few feet of approach. 

This rule documents the minimum sensor configuration used in docking database generation. 

A successful docking may be possible without one or more of these sensors given a wide 
margin for error in the propellant budget, plume loads, docking loads, capture probability, 
and docking time. 

1. PRIOR TO DOCKING, THE APPROACH WILL BE ABORTED AND 
A CORRIDOR BACKOUT INITIATED IF REGAINING A 
REQUIRED DOCKING SENSOR IS POSSIBLE. 

If regaining one or more of the required docking sensors is possible, then it is prudent to abort 
the approach in an effort to regain those sensors (via centerline camera replacement, TCS 
thermal conditioning, HHL 1FM, etc.). Performing a corridor backout while sensor 
troubleshooting is underway will minimize plume loads on the ISS. ©[102398-6753A] 

THIS RULE CONTINUED ON NEXT PAGE 
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2. IF THE FULL COMPLEMENT OF REQUIRED SENSORS CANNOT 
BE REGAINED, CONSIDERATION WILL BE GIVEN TO 
CONTINUING THE APPROACH TO DOCK ON A BEST EFFORT 
BASIS WITH THE INCREASED POSSIBILITY OF EXCEEDING 
ISS STRUCTURAL LOAD LIMITS. ©[102398-6753A] 

Continuing the approach to dock without the full complement of docking sensors significantly 
increases the risk of exceeding ISS structural load limits. Specifically, the degraded sensor 
complement can lead to approach trajectories and shuttle jet firings that are outside of analyzed 
performance envelopes, resulting in plume loads that exceed ISS solar array structural limits. 
Furthermore, contact conditions may be sufficiently off nominal that the ISS structural integrity is 
compromised or the docking mechanism is damaged to an extent that further dockings are not 
possible. These risks to ISS hardware must be weighed against mission objectives when deciding 
whether to continue the approach. 

FLIGHT/STAGE EFFECTIVITY: 2A.1 AND SUBS 

B. FOR ISS UNDOCKING OPERATIONS, A SENSOR CAPABLE OF 

MEASURING ISS LATERAL DISPLACEMENT FROM THE ORBITER 
DOCKING MECHANISM CENTERLINE IS REQUIRED. 

When the orbiter undocks and departs from the ISS, the pilot must maintain the ISS within an 8 
deg corridor relative to the orbiter docking mechanism centerline, necessitating the use of a 
centerline camera or equivalent sensor. This corridor separation ensures ISS structural load 
limits are not exceeded as a result of orbiter jet firings. For failure of the primary centerline 
camera, the backup centerline camera should be installed to support undocking operations. It is 
also possible, depending on the ISS configuration, to use other cameras (bulkhead camera or 
camcorder) or the COAS in conjunction with procedural updates to support orbiter undocking. 
For example, ISS structure that is centered in the COAS when the orbiter is positioned in the 8 
deg corridor can be used as a corridor reference. TCS in conjunction with RPOP is also capable 
of providing corridor position but is subject to reflector visibility. ®[1 02398-6753A] 

THIS RULE CONTINUED ON NEXT PAGE 
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C. FOR ISS FLYAROUND OPERATIONS, A FUNCTIONAL HAND-HELD 
LIDAR (HHL) IS REQUIRED. ©[102398-6753A] 

Flyarounds require the pilot to maintain a prescribed range from a specific target on the ISS. 
KU Radar is not considered a valid sensor to support flyaround operations because of the 
degraded measurements resulting from beam wandering over the length of the ISS. TCS is not 
considered a valid sensor to support flyaround operations because TCS reflectors are not visible 
at all times during a flyaround. The only sensor that provides precise ranging to specific targets 
on the ISS at all times is the HHL. Without an accurate ranging sensor, a flyaround at a specific 
range cannot be maintained. Plume loads analysis and propellant budgets assume range limits 
are maintained during flyaround operations. 

A centerline camera, although desirable, is not required to support a flyaround. At flyaround 
range, use of the COAS or other payload bay cameras is adequate to support flyaround 
operations. 

1. IF A FUNCTIONAL HHL IS NOT AVAILABLE PRIOR TO THE 
START OF A FLYAROUND, THEN THE FLYAROUND WILL NOT 
BE PERFORMED. 

2. IF THE LAST FUNCTIONING HHL FAILS DURING A 
FLYAROUND, THE FLYAROUND WILL BE ABORTED AND A 
BREAKOUT MANEUVER PERFORMED. 

If a functional HHL is not available during a flyaround, then a breakout must be initiated as 
agreed at Generic Joint Operations Panel #48 on March 10, 1998. ©[102398-6753A] 

FLIGHT/STAGE EFFECTIVITY: ALL FLIGHTS 
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11 Appendix B - GSFC Automated Fault Protection 

Missions run by Goddard typically use a combination of Telemetry Statistical Monitors 
(TSMs) and Fault Detection and Correction (FDC) for fault protection. These operate at 
the spacecraft or system level, and at the subsystem level respectively. The following 
discussion is in the context of the Power Subsystem Electronics (PSE) [10], a subsystem 
on EO-1. 


11.1 Automated Spacecraft Response: Telemetry Statistical Monitors (TSMs) 


The Telemetry Statistical Monitor (TSM) system is 
resident within the Mongoose V Command and Data 
Handling (C&DH) Processor. It provides fault 
protection across all subsystems, including PSE. The 
matrix of all TSMs flying on EO-1 is shown in the 
ASIST workstation display in Figure 1. 

Two levels of automatic fault protection are 
handled by TSMs. If these do not prevent the 
progress of the fault, a third level of automatic 
protection is provided by the FDC actions at the PSE 
subsystem Remote Service Node (RSN). There are 
four TSMs and RTS responses in the automatic 
protection system for power. The TSM actions will 
take place when out-of-limit conditions are 
experienced for Battery Differential Voltage, Battery 
Low Voltage, Battery High Temperature, and Battery 
Low State of Charge. For example, TSM #050 
checks for low Battery State of Charge (BSOC): 

If BSOC < 85%, issue event message 

If BSOC > 30% and BSOC < 70%, 
call Safe Power (RTS #19) 



Figure 1: EO-1 TSM Matrix 


When the parameter being monitored by the TSM exceeds the first (most sensitive) 
level of limit violation, the TSM will issue a limit violation event message after three 
consecutive violations. If the parameter telemetry value continues to degrade and the out- 
of-limit reading exceeds the second limit level (more severe violation), the TSM will 
issue a series of preprogrammed commands to attempt to protect the spacecraft and 
correct the limit violation. The commands initiated by the TSM are Relative Timed 
Sequence (RTS) commands, designated by individual sequence numbers. For TSM #050, 
RTS #19 initiates the loadshed and safehold sequence. 

TSMs can be individually enabled and disabled. If a TSM often generates false 
positives, it can be disabled until a patch to the spacecraft software can be uploaded. This 
can also be used to allow the operators of the spacecraft to perform actions that were not 
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envisioned at design time, but are later detennined to be necessary and safe. For example, 
one TSM is tripped when the spacecraft instrument covers are open and the spacecraft 
begins to point toward the sun, which will damage the instruments. However, this 
maneuver is allowable when the spacecraft is in the Earth’s shadow. When the maneuver 
is necessary and safe, this TSM is disabled, then re-enabled after the maneuver is 
complete. 

The TSM matrix is inherently a non-intuitive user interface - unless the operator 
knows the TSM matrix very well, it does not provide insight at a glance. The operator 
must examine each effected TSM to determine the problem. TSMs do not identify root 
cause. A common failure - e.g., power - would cause the display to light up like a 
Christmas tree, as in Figure 1. 

The number of TSMs implemented for EO-1 was limited due to development effort 
and cost. Scalability is a challenge for rule-based systems, due to the lack of structure in 
the set of Fault Protection rules. 

1 1.2 Automated Subsystem Response: Fault Detection and Correction (FDC) 

FDCs provide health management local to each subsystem. The PSE RSN processor 
continuously monitors the power system spacecraft telemetry and automatically responds 
to certain telemetry limit violations in a similar but not identical fashion as the automated 
TSM response. The limits for the FDC are set to more extreme (forgiving) levels than the 
stricter TSM limits, the idea being that the FDC will kick in should the TSM fail to act. 
The logic flow chart for the 3 PSE FDCs is shown in Figure 2 below. 



Figure 2: EO-1 FDCs for the Power Subsystem Electronics 
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TSMs, with their stricter redlines, normally perform all loadshedding and safehold, since 
the PSE FDCs cannot load shed other subsystems. The PSE FDCs serve as a backup 
should the TSMs fail to trip. Each trigger on the left is linked to the corrective action(s) 
on the right. The first FDC corresponds to the low BSOC TSM #050. This FDC will 
trigger two actions if battery voltage drops below 25.2V. First it sets BSOC to 50% to 
force triggering of TSM #050 if it did not already trip for some reason. Second, a series 
of steps lower the battery charge rate to implement loadshedding by setting the 
Voltage/Temperature curve to 3 (normally the charge rate is 4.5). In addition, several 
parameters are set to their normal values: battery maximum current is set to 10A to 
prevent overcharging; trickle current is set to nominal 0.5A; and the battery C/D 
(charge/discharge) factor is set to 1.05, reflecting the fact that the battery is not perfectly 
efficient. 

The FDC automated response was designed for redundancy, so that spacecraft 
protection was still available from the subsystem RSN in the event the TSM protection at 
C&DH was malfunctioning. However, there is a potential for TSM/FDC conflict - it is 
quite possible that an FDC limit violation may occur after a valid TSM limit response 
was issued. In this case, TSM and FDC responses will be operating in parallel. The FDC 
and TSM responses had to be designed so that there are no conflicts between the two 
systems. 

Another limitation is that FDC corrective actions are limited to the scope of the 
subsystem, and any impact on other subsystems must be handled by TSMs. If system- 
level response is required, a TSM must be tripped to initiate wider recovery of the 
spacecraft. In this way the FDC which sets BSOC = 50% will trip TSM #50 to do load 
shedding and safehold. This relationship is implicit, and if improperly managed could 
result in unexpected behavior with potentially severe consequences. 
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